An operating system designed for mobile devices such as smartphones or tablet computers may be roughly divided into four main layers. The core of the operating system, or the base layer of the four layers in the operating system, is the kernel layer. The kernel layer is followed by the middleware layer in which, e.g., the Java libraries and the runtime machine reside. The second topmost layer comprises the application framework layer, and the topmost layer comprises the application layer. Each application residing in the application layer of the operating system comprises four component types. The first component type is an activity component that defines an application's user interface, the second component type is a service component that performs background processing, the third component type is a content provider component that stores and shares data using relational database interfaces, and the fourth component type is a broadcast receiver component that acts as a mailbox for messages from other applications.
When one component initiates communication with another, this communication process is known as inter-component communication (“ICC”). In an ICC process, a message object that contains a destination or target component address and data will be sent from the initiating component to a target component. The action associated with each ICC varies depending on the component that is the target of the ICC. As an example, a first application is set up with a first activity component and a first service component and a second application is set up with a second broadcast receiver component. In this example, the first activity component in the first application may initiate an ICC targeting the first service component to control the operation of the first service component in the first application. It should be noted that the inter-component communications are not limited to communications between components residing in a single application only. ICCs may also be used to facilitate the interaction between components in two different applications. Returning to the previous example, this would mean that the first activity component in the first application may initiate an ICC targeting the second broadcast receiver component in the second application to broadcast any messages that may be contained within the first application using the broadcast receiver of the second application.
To increase the portability of applications, the libraries in the middleware layer implement device-specific functions so that applications in the application layer and software modules in the application framework layer need not concern themselves with the variations between devices that utilize such an operating system. However, this results in an increase in the overall complexity of the operating system. Due to the increased complexity of the operating system, most application developers tend to overlook security loopholes. These loopholes may be exploited by malicious applications or services programmed to carry out malicious tasks or execute malicious codes. For example, these malicious applications or services may exploit the inter-component communications to gain access to sensitive components or data residing within applications.
By default, such operating systems have in place a security policy that protects applications and data at the ICC level. In particular, the operating system is provided with a reference monitor that resides at the application framework layer. The reference monitor provides mandatory access control (MAC) enforcement of how applications are to access components. In its simplest form, access to each component is restricted by assigning it an access permission label. These permission labels are typically assigned by the developers of the application and are usually not modifiable by a general user of the application. When a component initiates an ICC, the reference monitor checks the collection of permission labels assigned to the application that contains the initiating component as the initiating component will inherit the permission labels of the application. If the collection contains all the permission labels required by the target component of the ICC, the reference monitor allows the ICC to continue. Alternatively, if any required label is not in the initiating component's collection, the establishment of the ICC is denied. In having such a security policy in place, the developer of the application is actually the only person who is able to define the application's security policy or in particular, each component's required permission label or the list of permission labels associated with the particular application.
Throughout the years, various permission management applications have been developed to address the shortcomings of existing permission controls for such operating systems. These permission management applications provide for dynamic permission management which allow a user to independently revoke and grant some permission labels associated with certain applications after the applications have been installed. In general, these permission management applications may be broadly grouped into four categories, application package modification based applications, Read-Only-Memory based applications, Application Ops based applications and Root based application. These various types of applications attempt to address some of the shortcomings of existing permission controls for such operating systems.